With the advent of the computer age, computer and software users have grown accustomed to user-friendly software applications that help then write, calculate, organize, prepare presentations, send and receive electronic mail, make music, and the like. For example, modern electronic word processing applications allow users to prepare a variety of useful documents. Modern spreadsheet applications allow users to enter, manipulate, and organize data. Modern electronic slide presentation applications allow users to create a variety of slide presentations containing text, pictures, data or other useful objects.
According to prior methods and systems, documents created by such applications (e.g. word processing documents, spreadsheets, slide presentation documents) have limited facility for storing/transporting the contents of arbitrary metadata required by the context of the documents. For example, a solution built on top of a word processing document may require the storage of workflow data that describes various states of the document, for example, previous workflow approval states (dates, times, names), current approval states, future workflow states before completion, name and office address of document author, document changes, and the like. According to such prior methods and systems, the options for storing this information were primarily limited to the use of document variables or existing custom object linking and embedding (OLE) document properties that have several limitations. For example, such prior methods can only store name/value pairs (no hierarchical data). Such methods are limited to 255 characters maximum. Such methods are built to contain only text. All properties for such methods are stored in a single store, for example, an OLE properties store, which means the properties have a possibility of conflicting. Further, such stored properties have no data validation because they are plain text. The result of these limitations is that it is difficult for users of such applications and related documents to store arbitrary data with documents, which is a common need of many users.
Another problem with prior methods and systems is that structured markup language data, for example Extensible Markup Language (XML) data may not be concurrently edited by multiple clients (for example, multiple add-ins each independently running in the context of a word processing document.) However, in the context of many documents, there is a higher likelihood that the scenarios involving this metadata will require concurrent editing by one or more sources.
Accordingly, there is a need for a data store for storing and relating data associated with a computer-generated document and for allowing use and manipulation of such data by one or more software applications. It is with respect to these and other considerations that the present invention has been made.